NetNews Offline 2/NetNews Offline Volume 2.iso/news/comp/sys/amiga/programmer/1876

Text File | 1996-08-05 | 5.8 KB | 152 lines

Path: informatik.tu-muenchen.de!fischerj
From: [e-mail] (Juergen "Rally" Fischer)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: Demo/game to OS friendly part II
Date: 24 Jan 1996 15:42:56 GMT
Organization: Technische Universitaet Muenchen, Germany
Distribution: world
Message-ID: <4e5k20$[e-mail]>
References: <4e0jhq$[e-mail]> <4e114i$[e-mail]> <4e371l$[e-mail]> <4e3jld$[e-mail]>
NNTP-Posting-Host: hphalle5.informatik.tu-muenchen.de
Originator: [e-mail]


In article <4e3jld$[e-mail]>, [e-mail] (Michael van Elst) writes:
|> [e-mail] (Juergen "Rally" Fischer) writes:

|> If you want hacks then shut down the system and reboot afterwards.
naah, shut down, zzzt zzzt, how should I perform parallel reload from
hd then ? :)

|> And stand for it.
Or embed it into OS as much as possible, tell the user, and stand for it.

|>
|> If you want the advantages of system-compliant code then use the
|> OS and don't mix OS and hacks.

If I also give user the possibilty to chose OS-only fallback-mode,
it's all a la RKM, and no need for you to flame. Your A3000 (assuming
gfx-card) will run it, too ;)

But writepixelarray8 is known to be slower on current chipset Amigas...

Well, the medium version, checking for native bitmaps (can I assume
blitter present then ?) and using less optimal 4 pass blitter should
also still be a la RKM, but will loose on 2x2 quite much speed
vs the hack. realtimish demos on 1x1 will also loose quite some fps.

So if user got AGA and PAL he will be happy chosing the hack.

|>
|> >yes, in can optimize that way, but this could still be less ideal
|> >than direct render to vram.
|>
|> Sure. In the same way that WaitTOF() could suddenly busy-wait, no ?

Do I read this right as "I don't believe direct render can be faster" ?
not in demos with realtime-fx, especially 50Hz ones ?

|>
|> >??? the driver can give you fastmem, chipmem, vram, swapspace,
|> >whatever depending to architecture...
|>
|> And your code has to adapt to it. It even has to follow rules.

struct display *getdisplay(320,256,8,MODE_DIRECT_RENDER|MODE_LORES);

char *display->render

render to given buffer.

then call updatedisplay(struct display *)

which will do nothing in the DIRECT_RENDER mode, or copying in other modi.

gives optimum speed, and code doesn't have to adapt to anything.
maybe lacks some things like network support ;)

|>
|> >|> But why should writing bytewise be faster ?
|> >texture mapping loops write bytewise to fastmem. If vram is as fast,
|> >you can render into it and save the time of copying.
|>
|> How would you know ? For most systems the VRAM wouldn't be cachable.
|> Each write access is passed to the RAM. So, writing bytes causes
|> 4 accesses per word. Writing to (write-)cached FastRAM and copying
|> later just causes 3 accesses per word.

Well, heehee, there have been cases where even a A1200 rendering to
_CHIPMEM_ was faster than using fastmem+copy. This proves my point
(which is "rendering to vram could be faster on a certain machine
running a certain gfx-engine").

|> >On architectures where vram is quite quick and fastmem is quite slowe and
|> >copying is done with cpu it does need that. This time you are the one that
|> >doesn't take care of all possible architectures!
|>
|> I don't have to, the driver does. But your code has to. It even has
|> to take into account every possible combination of framebuffer, CPU,
|> bus architecture, etc..

mhm, how does your idea handle the case "direct render" ?

|>
|> >you are talking about a game on wb window ? I hope also future Amigas
|> >will provide 320 pix fullscreen. that's what games just need.
|>
|> Some future Amigas will not provide 320 pix fullscreen.

ugh. look at all those "cool workastions", SGI, wow how cool it is,
we love it, but no fullscreen animation, or jerk jerk. just because
they got no lores.

The philosophy of Amiga has always been beeing efficient.
having lores modi for lo cpus (or even lolores, quick 160er modi
by blitter, or even lololores, beyond 160, but outzoomed _for free_
(copperscreen)).

At least the AMIGA hardware can do it, but some people tell
not to use it ;)

|>
|> Some graphics cards might provide a 320 pix fullscreen by zooming
|> a tiny bitmap in hardware.

that's ok, if it can be done far beyond a frame (it's DMA should not
slow down direct render) then it's ok. If the hires_only causes
slowdown vs the same card but having lores, then it's bad.

workstation fans smile a bit when watching A1200 doom running
quarterscreen (anyway, when using 'hacks' you can get fullscreen
2x2 faster than OS-quarterscreen 1x1 on the A1200!).

But wouldn't it be more annoying if you got a quick cpu but run also
quarterscreen due to not having lores ? would be really lame.

|>
|> Even more for your code to consider.

no. If I had designed the interface, setdisplay(struct display *) would
handle the outzoom without application noticing it.

|>
|> >what ? I say a game programer is more likely to use OS if it's excelent
|> >in speed end got a useful interface.
|>
|> I say that a c00l c0d3r (and that's most of all game programmers we
|> have) does never use the OS. Even your proposals for low-level access
|> to graphics hardware are just a way to avoid the OS as much as possible.

not acess to hardware, just to a buffer that can be on the card if
possible!

|> --
|>                                 Michael van Elst
|>
|> Internet: [e-mail]
|>                                 "A potential Snark may lurk in every tree."
------------------------------------------------------------------------
   [e-mail] (Juergen "Rally" Fischer)   =:)